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Abstract 

An expert system which diagnoses various seal leakage faults in the High Pressure 
Oxidizer Turbopump of the Space Shuttle Main Engine was developed using G2™ real-time 
expert system. Three major functions of the software were implemented: model-based data 
generation, real-time expert system reasoning, and real-time input/output communication. This 
system is proposed as one module of a complete diagnostic system for Space Shuttle Main 
Engine. Diagnosis of a fault is defined as the determination of its type, severity, and likelihood. 
Since fault diagnosis is often accomplished through the use of heuristic human knowledge, an 
expert system based approach has been adopted as a paradigm to develop this diagnostic system. 
To implement this approach, a software shell which can be easily programmed to emulate the 
human decision process, the G2 Real-Time Expert System, was selected. Lessons learned from 
this implementation are discussed. 


Introduction 

An Intelligent Control System (ICS) for a Reusable Rocket Engine was proposed in [1], 
Implementation of such a system requires the real-time diagnosis of a fault mode and/or a 
prognosis of an impending failure. A hierarchical, decentralized diagnostic system was proposed 
in [2] for the Real-Time Diagnostic System component of the ICS framework. This paper 
describes the on-going research progress on the implementation of this ICS Diagnostic System 
at NASA Lewis Research Center. Figure 1 shows the proposed diagnostic system which has 
three "layers" of information processing. These are condition monitoring, fault mode detection, 
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and expert system diagnosis. The condition monitoring layer is the first level signal processing. 
Here, important features to be used in the diagnostic system are extracted from the incoming data 
stream and processed. The processed data are then used by the higher level fault mode detection 
layer to do preliminary diagnosis on potential faults at the component level. Because of the 
closely coupled nature of the rocket engine propulsion system components, it is expected that a 
given engine condition may trigger more than one fault mode detector. For example, a surge in 
the pump outlet temperature measurement on the low pressure fuel turbopump (LPFTP) may 
trigger an alarm on the sensor failure detector as well as the LPFTP seal leakage fault mode 
detector. Expert knowledge is needed to resolve the conflicting reports from the various failure 
mode detectors. This is the function of the diagnostic expert layer. Here, the heuristic nature 
of this decision process makes it desirable to use an expert system approach. 

Implementation of the real-time diagnostic system described above requires a wide 
spectrum of information processing capability. Generally, in the condition monitoring layer, fast 
data processing is often needed for feature extraction and signal conditioning. This is usually 
followed by some detection logic to determine the selected faults on the component level. One 
example is the neural network approach for real-time sensor validation which includes failure 
detection, isolation and accommodation [3,4], In these references, the neural network is used to 
process the incoming data to generate on-line estimates of sensor values and the sensor failures 
are detected by the comparison of estimated and measured values. Another example is the 
model-based failure diagnosis system using on-line parameter identification techniques where 
input data is processed to estimate important parameters for the predefined fault detection logic. 
It has been demonstrated to be very effective in detecting actuator failures in the operation of 
reusable rocket engines [5,6]. Besides these model based diagnostic schemes, there are still a 
large number of failure modes which can be diagnosed by the heuristic expert knowledge. One 
example of this is the High Pressure Oxidizer Turbopump (HPOTP) diagnostic procedure used 
by field experts [7]. Finally, the distributed diagnostic system requires another level of 
intelligence to oversee the fault mode reports generated by component fault detectors. The 
decision making at this level can be best done using a rule-based expert system. Figure 2 shows 
the current setup for the implementation of the distributed diagnostic system in the NASA-Lewis 
ICS group. In this paper, only the turbopump seal problem will be discussed in detail. 

There have been many studies on the High Pressure Oxidizer Turbopump failure modes 
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[7-10]. The seal system between the liquid oxygen and hot gas is recognized as one of the most 
critical items in the operation of a reusable rocket engine. A model for the seal system in the 
High Pressure Oxidizer Turbopump has been developed and is described in [10]. The trends of 
the sensor measurements for various seal failures are also discussed there. An implementation 
of this model is used by the expert system to detect seal failures as well as to estimate the 
parameter values which are not measured. 

Selecting a Real-Time Expert System Shell 
After reviewing currently available software shells in the artificial intelligence field, the 
expert system software G2™ by GENSYM™ Corp. was selected based on three main criteria: 
(1) its flexibility in expanding the knowledge base; (2) its capability to perform numerical 
simulation; and (3) its capability to perform real-time input/output operations. 

The G2 software package provides a rule-based inference engine which is essential for 
the future expansion of the knowledge base to be implemented. Historically, in the diagnostic 
process, a decision tree type of implementation has been the preferred paradigm because of its 
simplicity [7]. However, since the present ICS program is a research project, it is important to 
keep the knowledge base expandable for future development. Thus, a "real" expert system shell 
using an inference engine is desired because of the ease of adding rules. Another important 
feature of G2 is its integrated simulation capability. A numerical model can be programmed in 
the simulator to provide a possible source of values for variables. This simulation facility 
provides the potential of testing the knowledge base under development without connecting to 
an actual system. It also provides the option of using a model-based diagnostic system when the 
input information is incomplete. Along with the expert system shell, a standard interface called 
GSI™ can be set up to provide real-time input/output data. The real-time inference engine has 
the capability of reasoning about the continuously changing environment using the sensor data. 

Knowledge Representation of the HPOTP Seal System 
There are three types of knowledge to be built into a typical G2 expert system: (1) object 
classification; (2) simulation formulae; and (3) inference rules. 
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1. Object Classification 

All the objects in the application have to be described in terms of classes and subclasses. 
Hach class has its own specific attributes. For example, all types of seals belong to a general 
class called SEAL which has common properties like flow rate, seal clearance, etc. Under this 
general description of a seal there are different subclasses (types) of seals such as STEP-SEAL, 
LABYRINTH-SEAL and SLINGER-SEAL [10]. Each of these subclasses of SEAL will have 
its own attributes which are specific to the subclass. Figure 3 shows the object class definition 
in the HPOTP seal system. The major classes are INSTRUMENT-SIGNAL, INPUT-SOURCE, 
VENT-PORT, SEAL, DRAIN-LINE, MERGE-POINT, FLOW-LINE, and file handlers. Sub- 
classes for each major class are also defined in Figure 3. These class definitions are the building 
blocks for creating the HPOTP seal model. 

2. Plant Model and Data Server 

Having defined the classes of objects that are used in the application, specific instances 
can be created to represent physical components of the system under study. All instances are 
then placed on a workspace and connected according to their relative relationships. Figure 4 
shows the schematic of these objects. The schematic constructed in Figure 4 represents a 
complete seal system including the physical connections of the components. Flow lines are used 
to show the actual material transfer between components. Figure 5 shows the description of the 
prime seal which is adjacent to the turbine discharge. Important attributes of this object are flow 
content, flow rate, status (ok or failed), and clearance. The super class of this object is the 
STEP-SEAL. 

As mentioned above, the relationships between objects are established through 
connections. However, the values of attributes are obtained through three mechanisms; sensor 
inputs, simulation formulae, and inference rules. If a sensor measurement is available for a 
particular variable that G2 is simulating, an external sensor input can be connected to that 
variable. This is done by the real-time communication through GSI™ (G2 Standard Interface) 
which handles the data stream received. The second method of obtaining variable values is 
through simulation formulae. The G2 simulator can evaluate algebraic equations, difference 
equations, and first order differential equations. In fact, the simulator is usually used as a 
separate piece of software — a data server that exists to provide simulated values. It can also 
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serve either as a diagnosis tool or an estimator for important parameter values that are not 
measured by sensors. In the former case, the simulator may be used to compare observed values 
with simulated values in detecting system faults. The third mechanism for obtaining variable 
values is by using G2 rules which conclude the necessary values. The G2 rules and the inference 
engine are discussed in the next session. 

3. G2 Rules and Real-Time Inference Engine 

G2 rules contain experts’ knowledge of what to conclude and how to respond to given 
sets of conditions. Rules have two basic parts, an antecedent that lists the conditions, and a 
consequent that shows what to conclude and what actions to take [11]. Rules can be specific to 
the condition of a component or generic to an object class. When a rule is invoked by the 
inference engine, the antecedent is first evaluated to determine if it is true. If it is, the actions 
in the consequent are executed. The actions of the consequent in G2 might include: determining 
a variable’s value, sending a value to an external destination, informing the user, activating or 
deactivating a specific set of knowledge bases, etc. In the HPOTP seal failure diagnostic system, 
rules are used mainly for the purpose of detecting predefined failure conditions. Figure 6 shows 
some of the rules used in the HPOTP seal problem diagnosis. 

A major part of G2 is the real-time inference engine. It reasons about the current state 
of operation, and presents the import findings to the end-user or initiates other activity based on 
the defined rules contained in the knowledge base. Besides forward chaining and backward 
chaining methods in evaluating rules, the G2 inference engine also uses special techniques like 
scanning, focusing, and invoking, which are designed specially for time critical applications [11]. 
Currently, in the HPOTP seal failure diagnostic system, only backward and forward chaining 
methods are used because of the simplicity of the system. Nevertheless, it is expected that the 
other techniques will be utilized in the higher level diagnostics in the future. 

Discussion 

Our experience with G2 as a tool for providing real-time knowledge based decision 
making has been positive in general. G2 is rich in representing different kinds of domain 
knowledge. Its rule editor is very user friendly and English-like for easy understanding. Its 
simulator can be used as separate a simulator as well as a model for on-line estimation. Most 
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importantly, the uniqueness of G2 is its real-time inference engine. The real-time inference 
engine is capable of managing the "current status" using updated information. Expired variable 
values will be automatically replaced by new measurements or simulated values. 

However, there are also some shortcomings of G2. One of the problems is its sampling 
rate. The defined minimum sample interval is one second. This is not fast enough for rocket 
engine fault diagnosis. G2 is currently used in the ICS demonstration project in a "pseudo" real- 
time way (scaled time simulation). We expect that G2 will let us gain insight into how the real- 
time decision making process should be handled. Another problem that has been encountered 
is that any modification of the user-defined class relationship will not automatically pass to the 
existing instances (objects). Consequently, any major modification or expansion in the class 
definition will require extensive efforts to regenerate the existing knowledge base. Finally, the 
G2 graphic editor has a limited selection of defined icon components. As a result, creating the 
required new icons for system objects has added a great deal to the development time. 

Summary 

In this paper, some of the research in progress on the real-time diagnostic system for 
reusable rocket engines has been described. A distributed approach has been adopted to 
implement the ICS real-time diagnostic system. The G2 real-time expert system has been 
selected to encode the expert diagnostic knowledge. Details of the High Pressure Oxidizer 
Turbopump Seal system were modeled in G2. It was found that G2 performed reasonably well 
on the ICS demonstration using the Space Shuttle Main Engine simulation data from an AD 100 
computer. More complete research results on this research will be included in future reports. 
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Figure 1 . Distributed Diagnostic Architecture 
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Figure 2. ICS Real-Time Diagnostic System 
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Figure 3. Class and Subcalss Definition of the HPOTP Seal System 
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Figure 4. G2 Representation of HPOTP Seal System 
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Figure 5. HPOTP Prime-Seal as a G2 Object 


if the status of any step-seal is failed then 
change the color-pattern of the step-seal 
so that foreground-color is cyan 


if (the pressure of cavity-1 < 125) and (the 
pressure of cavity-2 > 25) then conclude 
that the status of second-seal is failed 


if the pressure of cavity-1 > 400 then 
conclude that the status of prime-seal is 
failed 


Figure 6. Examples of G2 Rules in HPOTP Seal Diagnosis 
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